A0-A077  427  MARYLAND  UNIV  COLLEGE  PARK  DEPT  OF  COMPUTER  SCIENCE  F/G  5/2 

THE  STRUCTURE  OF  SPECIFICATIONS  AND  IMPLEMENTATIONS  OF  DATA  APS--ETC(U) 
SEP  79  M  A  ARDIS  »  R  G  HAMLET  AF0SR-77-31B1 

UNCLASSIFIED  TR-801  AF0SR-TR-79-U54  ML 


1  OF  | 

AO 

A077427 

i 

g§ 

s 

\4 

Q 

n 

1 

0 

s 

1 

1 

H 

S|!?« 

LLI  °=  _ 

7j  TR-801 


/  ]  ' S«pl 


The  Structure  of  Spec 1 fleet  Iona  and  lapleaentations 

*  of  Data  Abstractions. 

*  •  > 


Mark  A.  Ardls 
>r  Richard  G.  Haalet 


r 

rip  -  i'  r 


■fC  ) 


COMPUTER  SCIENCE 
TECHNICAL  REPORT  SERIES 


D  D  C 

?i?or?nri  pr 

NOV  30  13R 


UNIVERSITY  OF  MARYLAND 

COLLEGE  PARK,  MARYLAND 
20742 


•  b  xl 


xl  Z  i  j  65 

Mprsead  far  public  release  i 
HttrtkutUn  ttllaltM, 


Department  of  Computer  Science 
University  of  Maryland 
College  Park,  Maryland  20702 


S  N3V  30  1379 

llEjs&Tnm. 


The  work  reported  here  \ 

Jcientiflc  Research  *<< 
omputer  Science  Center 


was  supported  by  a  grant  fro*  the  Air  Force  Office  of 
AFOSft^rlrrj* ) ,  Computer  tlae  was  provided  In  part  by  the 
of  the  University  of  Maryland. 

lttSA-n-3i8l  ! 


air  FvK::  rue*,  or  i  ■■  m  ; .  j 

ROTI'K  or  TPAMSXIT.'t:.  ■; 

This  tech:  '.c;«l  w  rt  .. 
npp-ovr.:  for  p  ;1  c  r  .  ..j  j. 

Distribution  la  unltoited. 

A.  D. 

Techntcnl  Inf  orssntion  Officer 


Structure  of  Specification*  and  Implementation* 


Ardls  I  Hamlet 


functions.  An  lneulelve  abstraction  Is  unconnected  with  formalise:  the  sets 
and  functions  are  supposed  to  be  known  sb  lnltlo.  Formal  Ideas  enter  when  the 
abstraction  la  (1)  implemented,  a  cony sinFlonai  program  written  to  carry  out 
the  operations  on  actual  cstal  and  (14)  specified,  a  mathematical 
characterisation  given  to  precisely  deacrlo*  its  sets  and  functions.  The 
intuitive  abstraction,  an  implementation,  and  a  specification  ahare  a  syntax 
that  nmees  the  sets  and  functions,  and  gives  the  function  domains  and  ranges 
(aa  set  names).  The  central  question  for  any  particular  example  of  syntax  Is 
whether  the  semantlce  of  the  three  Ideas  correspond:  does  the  collection  of 
objects  and  operatlona  a  human  being  was  thinking  of  behave  in  the  way  the 
Implementation's  data  and  procedures  behave?  Do  the  mathematical  entitles 
behave  as  Imagined?  The  questions  can  never  be  answered  precisely,  because 
the  Intuitive  abstraction  is  imprecise.  On  the  other  hand,  precise  comparison 
of  specification  and  implementation  Is  possible. 

This  paper  preeents  an  algebraic  comparison  of  specifications  with 
Implementations.  It  is  shown  that  these  abetractions  always  overlap,  and  have 
a  common  (lattice)  structure  that  Is  valuable  in  understanding  the 
modification  of  code  or  specification.^  However.  In  dealing  with  the  precise 
ent It  lee  subject  to  formal  analysis,  wiaust  not  lose  sight  of  the  Intuition 
behind  then.  Therefore,  our  definitions  are  framed  In  terns  of  the  Intuitive 
abetractlon  a  person  attempted  to  spedlfy' or  Implement,  and  we  refer  the 
algebraic  Ideas  to  this  standard  whenever  possible. 

Section  l  presents  the  Intuitive  Ideas  of  an  abstraction.  Its 
Implementation,  and  specification.  The  Ideas  are  essentially  those  of 
[Hoars  72  J  and  [Cuttag  7  7).  Section  2  gives  the  cosmon  formalism  to  be  used, 
the  constant  word  algebra.  In  Sections  J  and  *,  this  is  applied  to 
specification  and  Implementation.  Section  5  explores  the  overlap  between  the 
ldees,  and  suggests  that  the  precise  connection  can  shed  llpht  on  the 
Imprecise  one  that  Is  really  of  interest:  the  intuitive  abstraction  In  a 
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l.  Oats  Abstractions 


A  data  abstraction  Is  viewed  In  thraa  distinct  ways  In  this  papsr. 
first,  as  an  Intuitive  objact,  an  abstraction  Is  a  collection  of  sets  and 
sapping s  among  than,  with  the  sets  and  mappings  hawing  an  Intuitive  existence 
In  the  mind  of  a  human  being.  (Perhaps  this  existence  Is  Cod-given,  as 
Kronecker  claimed  of  the  natural  nimbers;  perhaps  It  Is  man's  handiwork;  from 
whatever  source  we  have  It  whole.)  Second,  an  abstraction  Is  what  a 
programming  language  supporting  type-encapsulation  delivers.  In  the  SIMULA 
CLASS  (Dahl  et  al.  701,  the  CLU  cluster  tLlakov  et  al.  77J,  and  the  SIMPL-0 
CUSS  (Cannon  k  Rosenberg  78],  these  languages  provide  the  programmer  with  a 
means  of  implementing  what  he  had  In  mind.  But  once  written,  code  has  an 
existence  of  Its  own.  which  need  bear  no  relation  to  the  ldees  that  remain  In 
the  person's  mind.  And  third,  an  abstraction  may  be  given  a  formal, 
mathematical  definition.  Indeed,  one  branch  of  mathematics  Is  devoted  to 
giving  formal  shape  to  Intuitive  Ideas  like  numbers  and  sets.  As  anyone  who 
constructs  formalisms  knows,  they  also  scqulre  a  life  of  their  own,  and  the 
correspondence  with  Intuition  la  a  difficult  one  to  establish. 

The  ideas  of  Implementation  and  specification  of  an  abstraction  can  be 
made  formal  and  precise.  As  formal  notions,  they  are  Independent  of  each 
other,  and  both  are  Imperfect  mirrors  of  an  Intuitive  Idea.  The  fundamental 
definitions  of  this  paper  Involve  correctness  —  the  precise  statement  of  what 
it  means  for  a  formal  implementation  or  specification  to  agree  with  intuition. 
Such  definitions  necessarily  retain  a  nonmechanical  portion,  but  It  Is 
Important  to  know,  before  we  pass  to  analysis  of  the  formal  Idea,  exactly  what 
It  la  supposed  to  be  standing  In  for. 

The  three  Ideas  of  abstraction  share  a  syntax  that  names  the  collection 
of  sets,  names  the  functions,  and  gives  the  set  names  for  function  domains  and 
ranges.  The  definition  of  this  slxnaturt  (Section  2)  Is  unusual  In  that  It 
Includes  only  the  names  of  the  sets  and  functions,  not  those  objects 
themselves.  Host  definitions  of  computer  science  —  the  legendary  17-tuple  of 
automata  theory  for  example  —  Involve  sets  themselves.  Here  this  Is 
Inappropriate,  because  to  give  a  set  Is  to  give  a  meaning.  The  signature 
consists  of  names;  when  objects  are  attached  to  those  names.  It  is  the 


Ardla  A  Hamlet  —  Structure  of  Spool float ions  and  Implementations 


3 


definition  of  the  abstraction  Itself.  If  the  assignment  to  the  oases  arises 
from  code,  we  have  the  implemented  abstraction;  If  It  arises  froa  soae 
aatheaatlcal  description,  the  specified  abstraction;  and  behind  It  all  are  the 
sets  and  functions  of  the  Intuitive  abstraction.  Much  of  the  power  of  formal 
Ideas  coaes  froa  a  convenient  confusion  of  syntax  with  seaantlc  substance:  we 
calk  about  the  coaplete  entity  as  If  It  had  only  syntax.  This  confusion  la 
too  expenslvs  here,  because  with  three  possible  meanings,  we  can  never 
explicate  the  relationships  aaong  then  froa  their  coaaon  naaea. 

It  Is  Impossible  to  be  sore  precise  about  the  Intuitive  seaantlcs  that 
sight  be  assigned  to  a  signature  than  to  say  that  a  huaan  being  Imagines 
particular  sets  and  particular  functions  defined  on  those  sets  to  be  the 
signature  naaes.  Then  the  Intuitive  abstraction  Is  coaplete. 

The  best  exaaple  of  an  Intuitive  abstraction  Is  the  natural  nuabers.  The 
set  Is  sn  Infinite  one,  containing  a  distinguished  eleaent  0  ,  and  there  Is  a 
generating  function  S  (Successor)  that  produces  the  other  elements,  all 
distinct:  S(0),  S(S(0)),  ...  Other  less  fundamental  operations  such  as 
addition  and  multlpl lent Ion  can  be  defined.  These  are  all  so  familiar  that  to 
name  Chen  Is  to  feel  that  they  are  known  and  understood,  exactly  the  character 
that  Intuitive  abstractions  have.  It  Is  Important  to  separate  the  Intuition 
from  any  formal  treatment  (here  for  example  the  objects  defined  by  the  Peano 
axioms),  since  thr  Identity  of  formal  and  Intuitive  objects  can  never  be 
proved,  and  we  want  to  avoid  an  Infinite  regress  by  grounding  our  definitions 
on  what  a  hissan  being  has  In  mind. 

1. 1.  Implementation 

For  an  Implementation  we  can  be  precise.  A  programming  language  Is 
Involved,  with  a  well-defined  semantics.  The  language  has  some  built-in 
entitles,  and  the  ability  to  define  abstractions  as  extensions.  The  usual 
situation  Is  that  there  are  a  finite  ntasber  of  primitive  types,  along  with  a 
few  fixed  way*  to  construct  new  types  from  these.  The  language  has  a 
procedure-definition  facility.  In  which  parameters  and  returned  values  may  be 
any  of  the  bullt-ln  or  constructed  types.  A  date-abstract lon-def lnlng 
facility  allows  a  record  of  bullt-ln  types,  along  with  a  group  of  procedures, 
to  be  encapsulated  and  called  something  like  a  "class."  The  reeord 
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constitutes  the  Internal ,  hidden  representation  of  the  abstraction  to  be 
defined,  while  the  procedures  alone  are  visible  from  the  outside,  and  permit 
manipulation  of  this  data.  In  order  to  give  examples ,  we  must  have  a 
particular  syntax,  so  we  construct  one  In  a  Pascal-like  fashion,  for  example, 


glggg  Prise 

record 

Thing:  (old,  new,  borrowed,  blue); 
Value:  loL 
and  record: 


func  Vs; 


Val(T  ,  U:  Prise):  loLi 


m&d.; 


func  Bu: 

•  •  • 

sod; 

•  •  • 

•nd  pliaa 


Bulldd:  int):  Prise; 


The  only  aspect  of  such  a  program  fragment  that  Is  not  defined  by  the 
programming  language,  Independent  of  its  abstraction  facility,  is  the 
restricted  visibility  of  the  unnamed  record  that  begins  the  class.  Within  the 
ciss»  this  record  takes  the  class  name  (Prise  in  the  example)  and  nay  be 
aanlpulated  normally.  Outside  the  class  the  name  may  only  be  used  to  type 
declarations;  the  outside  program  may  not  refer  to  the  components.  Indeed, 
the  using  program  is  not  to  have  any  idea  of  what  constitutes  the  internal 
record.  Objects  of  the  defined  type  can  only  be  manipulated  by  passing  then 
as  parameters  to  the  procedures  within  the  claae.  (it  is  possible  to  use  the 
defined  type  without  declaring  any  objects*  For  the  example  above,  it  might 
aake  sense  to  evaluate  Val(Bulld(3)  •  Build(-3')  in  which  the  hidden  data 
storage  has  only  a  fleeting  existence.) 

In  aost  of  the  existing  date-abstract ion  programming  languages  the 
internal  record  (here  unnamed)  retains  values  from  call  to  call  of  the 
procedures  encapsulated  with  it.  That  is  ,  a  perslsent  internal  state  of  the 
£lggg  exists ,  and  each  declared  object  of  the  new  type  receives  a  unique 
version  of  this  state.  The  aotual  situation  can  be  captured  formally  by 
treating  the  Internal  record  as  an  additional  phantom  parameter  and  result, 
for  each  procedure.  For  simplicity  we  instead  define  our  Pascal-like  language 
so  that  its  records  are  local:  on  each  procedure  Invocation  the  record 

comes  into  existence ,  and  must  be  initialised  to  be  used  sensibly;  no  values 
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s re  retained  fro*  osll  to  call. 

Ths  aeanlng  of  s  new  data  sbstrsctlon  Is  well-defined  by  the 
programming- language  semantics:  ths  spproprlsts  records  snd  othsr  built-in 
quantltlss  srs  asnipulstsd  by  ths  procsdurss  Just  ss  If  ths  eli««  boundarlss 
were  not  prsssnt.  It  rsasins  only  to  give  ths  obvious  eorrsspondsncs  with  ths 
syntax  of  ths  signature  of  sn  sbstrsctlon:  ths  rsoord  within  s  ei»««  goes  with 
ons  sst  nsas  of  ths  signature ,  snd  ths  procsdurss  go  with  ths  signature's 
function  naass  ,  with  ths  doaalns  snd  rsnges  astchsd  up  ss  declared*  Ths 
built-in  types  also  astch  with  sst  and  function  naass  of  ths  signature*  Ones 
s  claaa  has  been  defined  in  this  way,  ths  new  type  (defined  by  ths  claee  nsas 
and  corresponding  to  ths  unnaaed  internal  record)  aay  be  employed  in  defining 
othsr  classes  Just  as  the  built-in  types  can.  Ths  aost  natural  way  to 
construct  a  coaplsx  definition  is  as  a  strictly  nested  hierarchy  ,  beginning 
with  a  class  that  uses  only  built-in  types;  however,  there  is  no  reason  to 
forbid  autual  interactions  except  those  that  are  not  well  deflnec.  Situations 
in  which  nothing  is  really  defined  can  be  detected  in  syntax  Just  as 
nonsensical  recursive  types  are  detected  [van  WIJngaarden  et  al*  76]. 

To  discuss  precisely  the  aeanlng  of  a  claaa  the  progressing- language 
semantics  aust  take  a  precise  fora,  snd  we  select  that  devised  by  Harlan  Mills 
[Linger,  Mills  4  Witt  79].  Each  built-in  prlaitive  type  corresponds  to  a  set 
of  intuitive  objects;  for  exaaple  ,  lnt  to  the  Integers,  enuaerated  types  to 
finite  sets,  etc.  Record  types  correspond  to  cross  products  of  the  sets  of 
their  components.  Procedures  correspond  to  aapplngs  aaong  the  sets  to  which 
their  parsaeters  snd  result  values  correspond.  Thus  for  exaaple,  in  the  claaa 
Prize  above  the  objects  are  Integers  Z  ,  a  certain  four-eleaent  set  W  for 
the  enuaerated  type  ,  and  for  the  special  record  ,  pairs  froa  Z  t  W  .  The 
functional  objects  are 

[Val]:  (Z  x  W)  x  (Z  x  W>  - >  Z 

[Build]:  Z  — >  Z  x  W  . 

The  felicitous  notation  of  surrounding  the  procedure  syntax  naae  by  brackets 
to  lndloate  the  aeanlng  function  was  Invented  by  Kleene  [Kleene  52].  The  aoat 
Interesting  snd  difficult  part  of  the  seaantlc  definition  of  the  programming 
language  is  here  oaltted  ,  In  which  It  Is  spelled  out  which  particular 
functions  [Val]  and  [Build]  happen  to  be.  The  particular  ones  ere 
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(lateral nad  by  tha  aeanlng  of  tha  (alidad)  bodlaa  of  tha  procaduraa.  Roughly, 
tha  propar  function  la  that  ona  that  agraaa  with  tha  collaotion  of 
input-output  values  arising  froa  tha  procadura  execution.  To  fill  in  tha 
dataila  of  tha  dafinltion  requires  consldaratlon  of  how  aaoh  coaputatlonal 
feature  of  tha  languaga  works.  A  definition  along  thaaa  linaa  for  a  slapls 
language  is  given  in  coaplata  detail  in  [Haalat  78]. 

A  rieea  of  the  progressing  languaga  can  now  be  aada  to  provide  a 
sea antics  for  a  signature  ,  by  aatching  up  its  types  with  tha  sat  naaas  ,  and 
its  procedures  with  tha  function  naaas.  If  this  can  be  dona  consistently,  tha 
class  can  be  said  to  <■*!•— nr.  tha  signature,  and  give  it  a  aeanlng ,  the 
implemented  abstraction.  Any  given  signature  can  be  iapleaented  in  aany  ways  , 
because  procadura  bodies  in  tha  coda  are  not  constrained  by  tha  necessary 
correspondence.  Siallarly,  any  iaplaaants  soaa  signature,  naaaly  tha 

ona  in  which  tha  naaas  are  siaply  taken  froa  its  types  and  procedures.  For 
example,  tha  clean  Prize  above  iaplaaants  a  signature  with  two  sat  naaas  s 
and  t  and  two  function  naaas  f  and  g  ,  such  that  f:  a  x  s  — ->  t  and 
g:  t  — >  s  . 

Tha  c-.rrert.neaa  of  an  iaplesentat ion  Bust  be  relative  to  an  independent, 
intuitive  idea.  If  we  have  an  intuitive  abstraction  in  Bind,  than  an 
ispleaentation  abstraction  with  tha  saaa  signature  is  correct  if  tha  aeanlng 
of  tha  programming-language  entities  alaics  that  of  the  intuitive  ones 
exactly.  That  is,  each  function  coaputed  by  tha  prograa  Bust  agree  with  tha 
corresponding  intuitive  function.  Unfortunately  ,  this  agreeaent  can  be 
attained  only  through  an  additional  intermediary  ,  becauae  the  function  the 
prograa  coaputea ,  and  the  intuitive  functlona  ,  have  different  doaaina  and 
rangea.  In  an  intultve  abstraction  with  the  signature  of  the  above  exaaple , 
let  S  be  the  set  which  la  iapleaented  in  the  film,  record ,  and  let  Z  be 
the  integers  (which  int  implements).  Suppose  that  the  function  g:  Z  — >  S 
is  the  one  we  have  in  Bind  corresponding  to  the  procedure  Build.  (These 
symbols  stand  for  actual  seta  and  functions  now,  not  for  the  content-free 
naaea  of  the  signature.)  Correctness  auat  then  aean  that  [Build]  --  the 
function  coaputed  by  the  procedure  —  agrees  with  g  •  But  [Build]  does  not 
have  S  as  its  range;  rather  it  has  a  cross  product  set  that  is  the  aeanlng 
of  the  m«««  record.  What  is  missing  is  a  correspondence  between  elements  of 
the  class  record  and  eleaents  of  the  intuitive  set  S  •  We  know  that  these 
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sets  correspond  by  name,  but  without  an  exact  description  of  which  element 
corresponds  to  which,  it  is  impossible  to  state  the  condition  that  [Build] 
and  g  acres.  In  the  example,  the  ranee  of  [Build]  is  Z  x  W  ,  so  the 
mlsslnc  intermediary  is  a  map pine  that  associates  an  element  of  this  set  with 
an  element  of  S  ,  Let  this  mappine  be  R:  Z  x  W  — >  S  (for  Representation 
—  the  programming-language  pair  represents  the  abstract  object).  Correctness 
then  means  that  [Build]  and  g  acres  as  best  they  can:  that  given  any 
z  i  Z  ,  the  intuitive  function  and  the  implementation  produce  results  that 
acres.  In  symbols  for  this  case, 

g(x)  ■  R( [Build] ( 2 ) )  . 

A  more  graphic  way  to  present  the  same  statement  is  in  an  iepl«— ntatlon 
fiisersw  for  Build: 


[Build] 

Z - >  z  x  W 

If  the  diagram  commutes  ,  this  part  of  the  implementation  is  correct. 

When  the  formal  definition  of  correct  implementation  is  presented  in 
Section  a  ,  we  will  see  that  the  representation  must  be  taken  to  be  technically 
more  complicated,  in  order  to  capture  the  idea  of  laplementlnc  one  abstraction 
in  terms  of  another.  In  the  example,  the  simplification  is  that  we  have  taken 
Z  (the  integers)  to  be  the  same  set  as  a  programming-language  meaning,  and 
an  intuitive  abstraction.  Where  this  simple  correspondence  falls  ,  a  cross 
product  of  representation  functions  is  required  to  construct  the 
implementation  diagram.  Behind  the  technical  details  lies  the  Important  idea 
that  in  building  a  hierarchy  of  abstractions ,  lower  levels  may  be  imperfectly 
understood.  Formally,  this  imperfect  understanding  enters  through  selecting  a 
peculiar  representation  to  map  the  lower-level  abstractions  within  the 
higher-level  implementation  diagram. 

As  the  idea  of  "correctness*  la  framed  above,  it  describes  a  relationship 
among  three  Independent  ideas:  an  intuitive  abstraction,  a  program ,  and  the 
representation  that  links  their  sets.  In  practice,  the  intuitive  abstraction 
is  the  starting  point,  and  with  some  representation  in  mind,  a  program  is 
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written.  What  should  not  escape  notice  is  that  when  the  three  ideas  do  not 
match  to  yield  technical  correctness,  the  fault  aay  lie  with  the  code,  but  it 

•ay  also  (Independently)  lie  with  the  representation.  For  a  fixed 

representation  there  aay  be  any  maber  of  correct  lapleaentatlons  (including 
zero);  for  fixed  code  there  aay  be  any  nuaber  of  correct  representations 
(ditto).  In  Section  A  we  will  see  that  in  the  practical  case  where  the  code 
is  fixed  ,  a  collection  of  interrelated  correct  lapleaentatlons  results  as  the 
representation  varies.  Because  this  collection  has  a  simple,  tight  structure 
we  propose  It  as  w  good  way  to  think  about  groups  of  abstractions. 

1.2.  Specif lcation 

By  "specifications”  for  a  data  abstraction,  we  aean  a  aatheaatical 

formal  1 sa  that  describes  the  sets  and  functions  naaed  In  a  signature.  In 

aatheaatlcs  Itself,  the  discipline  of  "foundations"  is  concerned  with  giving 
formal  aeaning  to  intuitive  objects.  Set  theory  and  nuaber  theory  have  been 
aost  extensively  treated  ,  using  the  tools  of  aatheaatical  logic.  Abstract 
algebra  is  also  a  foundational  technique  ,  but  it  permits  use  of  definitional 
phrases  such  as  "the  unique  object  such  that..."  which  cannot  always  be 
Justified  by  a  construction.  For  the  specifications  to  be  used  here,  we 
combine  the  algebraic  approach  with  logical  ideas  to  give  the  relationship 
with  Intuitive  abstractions. 

Just  as  there  are  many  programming  languages  that  allow  the 
lapleaentation  of  data-abstractlon  extensions  to  their  types,  so  there  are 
aany  candidates  for  an  algebraic  specification  formalism.  These  all  have 
their  basis  In  formal  theories.  These  theories  have  a  syntax  oT  well-formed 
formulas  ( wfa 1  that  are  constructed  from  given  collections  of  symbols.  Wfs 
are  a  syntactic  idea,  in  that  no  aeaning  is  attached  to  a  particular  formula, 
but  there  are  precise  rules  for  a  formula's  construction. 

Froa  the  aany  choices  available,  we  select  a  particular  formallsa, 
essentially  that  of  [Guttag  77],  but  without  conditional  axloas.  The  symbols 
to  be  used  are: 

(D  Several  collections  of  distinct  variables,  each  unllalted. 

Each  collection  will  be  used  with  a  set  naae  froa  a  signature  (its 

tvna)  to  construct  a  finite  set  of  finite  wfs.  Thus  in  any 
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particular  case  a  finite  number  of  variable  collections  ,  each 
containing  a  finite  number  of  variables  ,  suffices. 

(2>  A  collection  of  function  symbols  ,  whose  number  la  similarly 
unlimited/ limited. 

(3^  A  collection  of  special  2-ary  equality- function  names,  each 
having  distinct  domain  D  x  D  for  some  set  name  D  ,  and  a  common 
range  (named  Boolean  1  .  written  ( infix  1  . 

(41  Parentheses  and  commas. 

Prom  these  symbols  the  usual  "terms"  can  be  constructed.  Each  term  has  a 
"type"  that  corresponds  to  a  set  name.  A  variable  Is  a  term,  of  the  type 
associated  with  its  collection.  A  function  name  is  a  term,  of  the  type  of  Its 
range,  provided  that  It  Is  followed  by  a  list  of  parameters  that  are  terms  of 
the  appropriate  types  to  match  Its  domain,  enclosed  In  parentheses  and 
separated  by  commas. 

Certain  terms  are  distinguished  as  "axioms."  These  are  of  type  Boolean, 
having  one  of  the  special  equality-function  names  as  the  outermost  symbol. 

All  variables  appearing  In  an  axiom  are  universally  quantified  by  default. 

The  way  In  which  we  use  the  formalism,  and  the  general  method  of  giving 
its  correspondence  with  Intuition  ,  do  not  depend  on  these  details  ,  but  some  of 
the  properties  of  the  formalism  would  change  if  they  were  changed.  In  any 
case,  a  specific  form  Is  needed  for  examples. 

For  example,  the  following  are  axioms, 

*  »U  u 

f(t  ,  g>  «T  t 

f(t  ,  u'  f(f(t  ,  v)  ,  v) 

If  for  two  set  names  T  and  U  (along  with  Boolean  B  )  ,  t  is  a  variable 

of  type  T  ,  and  u  ,  v  are  of  type  U  ;  and  ,  there  are  two  function  names 

f:  T  «  I)  — >  T  ,  and  g:  —  >  (1  ;  with  special  equality  functions 

T  x  T  — >  B  and  I)  t  II  — >  B  .  In  the  second  axiom,  f(t,  g)  Is 

a  term  of  type  T  ,  because  f  Is  a  function  name  with  this  range  ,  t  Is  a 
variable  of  type  T  ;  and  g  is  a  term  of  type  U  ,  because  that  Is  Its 
range,  and  It  has  no  parameters. 


— „ — ™- 
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The  correspondence  between  a  signature  ,  with  its  set  and  function  names  , 
and  a  set  of  axioms  ,  is  obvious.  Should  it  happen  that  there  is  a  consistent 
correspondence  between  the  appropriate  names  ,  we  say  that  the  set  of  axioms  is 
a  specification  for  the  signature.  This  notion  is  the  analogue  of 
"implementation”  of  a  signature  without  reference  to  any  intuitive  meaning; 
and  as  in  the  former  case,  since  the  substance  of  the  axioms  is  not 
constrained,  many  axiom  seta  specify  any  signature,  and  any  axiom  set 
specifies  some  signature. 

The  meaning  of  a  set  of  axioms,  which  defines  a  specified  abstraction 
analogous  to  the  implemented  abstraction  that  a  programming  language  defines  , 
is  not  so  well  known  in  computer  science.  This  meaning  is  supplied  by  the 
concept  of  a  "model"  from  mathematical  logic.  By  identifying  the  strictly 
formal  names  in  axioms  with  particular  set  elements  and  functions,  and  in 
particular  identifying  "Boolean"  with  the  set  ( true  .  false  I  and  the  special 
equality  functions  with  actual  equality  relations,  we  can  talk  about  the  idea 
of  "truth." 

SEFIHITIQH  —  An  IfllttrflTtttgtlufl  Of  a  set  of  axioms  is  a  mapping  that 
assigns  an  actual  set  to  each  type,  and  actual  functions  over 
appropriate  cross  products  of  these  sets  to  the  function  names.  In 
particular  ,  Boolean  must  be  assigned  ( true  .  false)  ,  and  each  "*" 
must  be  assigned  that  function  which  takes  the  value  true  if  and 
only  if  the  equality  relation  for  the  appropriate  set  holds.  An 
axiom  is  true  iA  an  interpretation  if  and  only  if  no  matter  which 
set  elements  under  the  interpretation  are  taken  for  its  variable 
symbols,  the  functions  of  the  Interpretation  ,  applied  to  these 
elements  ,  do  yield  true  for  the  outer  "«*  function.  The  sets  and 
functions  of  an  interpretation  that  makes  every  axiom  in  a 
specification  true,  is  called  a  model  of  that  specification. 

Ue  take  this  idea  as  the  semantics  for  specifications:  the  specified 
abstraction  is  any  model  of  the  axioms. 

For  a  particular  signature,  we  can  now  consider  another  pair  of  meanings, 
just  as  we  did  for  implementation.  A  set  of  axioms  that  define  a  specified 
abstraction  can  be  said  to  be  correct  relative  to  another,  intuitive 
abstraction  for  the  signature,  if  the  intuitive  abstraction  agrees  with  those 
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axloas.  The  technical  fora  of  this  stateaent  la  Just  that  the  Intuitive 
abstraction  Is  one  of  the  aodels  for  the  axloas.  That  Is  ,  there  aust  exist  an 
interpretation  aapplng  that  carries  the  axloa  formalism  onto  the  lntutlve  sets 
and  functions  ,  such  that  the  axloas  are  true  In  that  interpretation. 

An  interpretation  Is  as  essential  to  correctness  of  a  specification  as  a 
representation  is  to  iapleaentatlon.  (Indeed,  [Hoare  72]  uses  the  word  froa 
logic  for  the  latter  ldea.1  As  before,  It  can  happen  that  axloas  fall  to 
correctly  specify  a  given  Intuitive  abstraction,  not  because  of  an  error  In 
the  axloas  ,  but  because  the  correspondence  of  the  Interpretation  Is  in  error. 
However,  there  Is  lesr  leeway  for  coaaittlng  Interpretation  blunders  in 
specifications  ,  because  the  Interpretation  doaaln  has  no  naaed  structure.  A 
representation  sapping  carries  a  coaplex  record  object  to  an  Intuitive  one, 
and  the  sap  Is  likely  to  depend  on  the  record  structure  details;  the 
Interpretation  saps  only  hoaogeneous  sets, 

1.3.  Iapleaentatlon  vs.  Specification 

Data  abstractions  are  lapleaented  or  specified  by  people  beginning  with 
an  intuitive  idea  of  the  objects  and  operations  desired.  The  definitions  of 
correctness  above  relate  the  resulting  foraal  objects  to  what  a  person  had  In 
alnd.  But  In  practice  ,  only  the  foraal  objects  exist  for  analysis.  We  raise 
tne  question  of  the  extent  to  which  they  overlap: 

Suppose  that  a  certain  class  lapleaents  a  nuaber  of  Intuitive 
abstractions  correctly  ,  and  a  certain  set  of  axloas  correctly 
specifies  a  nuaber  of  intuitive  abstractions.  If  they  share  the 
saae  signature,  what  Is  the  relationship  between  the  classes  of 
intuitive  abstractions  they  correctly  capture? 

This  question  implicitly  raises  the  deeper  question  of  the  structure  of  the 
correct  Intuitive  abstractions  for  a  given  iapleaentatlon  or  specification. 

Because  the  details  of  the  foraal Isas  for  iapleaentatlon  and 
specification  are  so  different,  we  cannot  coapare  thea  without  a  coaaon 
theoretical  fraaework.  The  reaalnder  of  this  paper  Is  devoted  to  analysis  of 
such  a  fraaework  ,  a  word  algebra  of  constants. 
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2.  Word  Algebra 

Tha  ayntax  coaaon  to  an  lntulclva  abatractlon,  an  laplaaentad 
abatractlon.  and  a  apaclftad  abatractlon  la  capturad  In  tha  collactlon  of  aat 
and  function  naae*  callad  a  algnatura. 

DEFINITION  —  A  algnatura  la  a  pair  (S,  F)  conalatlng  of  a  flnlta, 
nonaapty  collactlon  of  aat  naaaa  S  (tha  aata  ara  callad  aorta) 
togathar  with  a  flnlta,  nonaapty  collactlon  of  function  naaaa  F  , 
tha  function  daaalna  balng  croaa  producta  of  aorta,  and  tha  rangaa 
aorta.  Tha  tupla  of  typaa  of  tha  paraaatara  of  a  function  la  callad 
Ita  arlty.  Function  naaaa  ara  conaldarad  to  lncluda  arlty 

Information.  Tha  notation  "f:  D  - >  R"  lndlcataa  that  D  la  tha 

daaaln  of  f  and  R  lta  ranga.  Whan  tha  arlty  la  laportant,  0 
will  ba  written  out  aa  a  croaa  product  to  ahow  it.  One  aort  la  tha 
d latlngul  a had  aort-of-lntereat . 

In  talking  about  a  algnatura.  It  la  laportant  to  reaaabar  that  only  naaaa 
ara  Involved.  For  example,  tha  algnatura  glvea  not  tha  aorta,  but  only  tha 
aort  naaaa.  Tha  diet lngulahed  naae  of  tha  aort-of-lntaraat  la  Intuitively  tha 
naae  of  tha  abatractlon  ltaelf;  tha  object*  of  thla  aort  ara  tha  onaa  to  ba 
defined  by  tha  abatractlon  that  uaaa  tha  naaaa  froa  tha  algnatura.  Fig.  2.1 
contain*  tha  algnatura  for  tha  Llat  data  abatractlon,  an  axaapla  wa  will  uae 
In  later  aactlona. 
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SCUTS 


Ll»C 

Clt 


FACTIONS 


EaptyL: 

— >  Llat 

Cone:  LI  at  x 

Llat  — >  Llat 

Ha  ad:  LI  at 

—  >  El  t 

Tall:  Llat 

Llat 

Ha  kail  at :  Clt 

— >  Llat 

On  a: 

— >  Clt 

Fl||ur«  2.1  Tha  slgnatura  of  tha  List  data  abstraction 
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Clven  a  signature  of  a  data  abstraction  there  exists  an  algebraic 
structure  of  possible  aeanlngs  of  that  signature,  t  lattice  of  semantic 
interpretations  derived  solely  froa  the  signature. 

DEFINITION  —  The  constant  word  alaebra  Wc  of  a  signature  (S,  F) 

Is  the  set  of  all  constants  formed  as  follows: 

(1)  Each  O-ary  function  f:  - >  Sj  In  F  la  a  constant  word  of 

type  Sj  . 

(2)  If  f:  S|X...sSn_j  — >  Sn  Is  a  function  In  F  and 

are  constant  words  of  types  Sj,  ....  S,,.!  ,  then 
f (w j, . ,wn„j )  Is  a  constant  word  of  type  SR  . 

(3)  Nothing  else  Is  a  constant  word. 

For  exaaple,  given  the  signature  of  Fig.  2.  1,  the  following  are  constant 
words: 

EaptyL 

Makel 1st (One) 

Cone (Makel 1st  (One) .Hake list (One) ) 

An  alaebra  Is  a  pair  (S,  F)  ,  where  S  Is  a  collection  of  sets,  and  F 
Is  a  collection  of  mappings  between  the  sets.  The  sets  of  Wc  are  named  by 
the  sorts  of  the  signature  and  the  aapplngs  are  named  by  the  function  names  of 
the  signature.  The  reason  for  defining  Wc  is  to  have  a  name  for  each  value 
of  each  sort.  No  natter  which  view  of  data  abstractions  Is  taken  (Intuition, 
specification  or  Implementation),  one  has  to  have  a  way  of  describing  the 
elements  of  sorts.  Wc  provides  a  name  for  every  element  that  Is  the  result 
of  some  sequence  of  operations.  If  one's  Intuitive  view  of  a  data  abstraction 
Includes  elements  of  sorts  that  cannot  be  generated  by  sequences  of 
operations,  then  W£  cannot  describe  those  elements.  However,  programming 
languages  that  support  type  encapsulation  do  not  allow  Implementations  of  such 
data  abstractions.  (Initialisation  of  variables  Is  an  operation  In  our  view.) 

2.  1.  Equal lty  In  Wc 

Two  different  sequences  of  operations  may  be  intended  to  produce  the  same 
value,  the  same  element  of  a  sort.  The  two  corresponding  elements  of  Vc 
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should  ba  equal.  U«  call  such  Intentions  seasntlc  Interpretations.  In  order 
to  define  this  idee  precisely  we  need  some  aatheaatlcal  terminology. 

DEFINITION  —  An  equivalence  relation  '  over  a  set  X  is  a  binary 
relation  eatlsfylng  the  following  properties,  for  all  x,  y,  s  In 
X  : 

( 1 )  x  ~  x  .  (Reflexive) 

12)  If  x  *  y  then  y  *  x  .  (Symmetric) 

(3)  If  x  *  y  end  y  "  s  then  x  *  x  .  (Transitive) 

A  conxruence  relation  on  an  algebra  ($,  F)  la  a  set  ("j)  of 
equivalence  relations,  one  relation  defined  on  each  set  Sj  6  S  , 
with  the  substitution  property: 

(4)  For  all  functions  f:  Stx...xSn_j  - >  Sn  , 

x t  *j  yt  ,  where  1  »  l,...,n-l  ,  leplles 

. *n-l^  n  l»  •  •  •  •  Fn-i )  • 

Sow  that  we  have  the  terminology,  we  say  precleely  what  we  mean  by  a 
semantic  lnterpretat Ion. 

PEFISITIOS  —  A  semantic  Interpretation  of  a  signature  la  a 
congruence  relation  on  Its  constant  word  algebra  Wc  .  We  eay  that 
two  values  of  Wc  are  equal  In  a  semantic  Interpretation  whenever 
they  are  related  by  that  congruence  relation. 

We  have  deliberately  choeen  an  algebraic  definition  for  "semantic 
Interpretation,"  because  we  wish  to  describe  Intuitive  data  abstractions  that 
have  been  correctly  specified  by  algebraic  axioms.  Perhape  It  la  a  surprise 
that  this  definition  applies  equally  well  to  implementations,  as  we  will  show 
in  section  4. 

Each  semantic  lntarpretatlon,  because  It  la  a  congruence  relation, 
defines  a  unique  algebra,  called  a  quotient  alaebra.  One  such  quotient 
algebra  behaves  Just  like  any  Intuitive  data  abstraction  for  a  signature. 

That  Is,  it  has  the  right  number  of  elements  In  each  sort,  and  each  function 
produces  the  right  value  for  each  set  of  input  values.  We  will  abuse  the 
terminology  slightly,  and  rafar  to  a  congruence  relation  aa  a  surrogate  for  a 
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abstraction  that  om  might  hava  In  mind.  It  would  ba  more  praclaa  to  aay 
thac  the  quotient  algabra  daflnad  by  tha  congruence  relation  la  the  surrogate. 
Uhara  there  la  no  chance  of  confualon  we  will  even  drop  the  "aurrogate  for" 
terminology  and  uae  the  tana  "semantic  interpretation"  when  we  mean  an 
Intuitive  data  abstraction.  We  summarise  these  conventions  as  follow*: 

ASSUMPTION  —  Every  Intuitive  data  abstraction  with  signature  S 
can  be  modelled  by  a  quotient  algebra  that  la  defined  by  a 
congruence  relation  on  the  constant  word  algebra  Wc  of  S  .  That 
la.  every  Intuitive  data  abstraction  has  a  surrogate. 

2.2.  Structure  of  Semantic  Interpretations 

Each  congruence  relation  on  W£  may  be  thought  of  ss  the  set  of  all 

pairs  of  constants  that  are  equal  In  that  relation.  Ue  thus  order  congruence 

relations  by  sec  containment:  a  congruence  relation  Is  contal  «d  In  another 
congruence  relation  If  and  only  If  It  Is  a  subset  of  the  other.  A  semantic 
Interpretation  la  contained  In  another  semantic  Interpretation  if  all  the 
constants  that  are  equal  In  the  first  sre  equal  In  the  second.  To  capture 
this  ordering  relationship  precisely  we  need  more  terminology. 

DEFINITION  —  A  partially  ordered  set  (A,  <)  is  a  set  A  with  a 
relation  <  satisfying  the  following  properties,  for  all 
a,  b,  c  6  A  : 

( 1 )  a  <  s  .  (Reflexive) 

(2)  a  <  b  and  b  <  a  Implies  a  -  b  .  (Antisymmetric) 

(3)  a  <  b  and  b  <  c  implies  a  <  c  .  (Transitive) 

A  lattice  Is  a  partially  ordered  set  In  which  every  two  elements 
have  a  least  upper  bound,  called  the  Join,  and  a  greatest  lower 
bound,  called  the  meet.  A  complete  lattice  L  Is  a  lattice  In 
which  every  subset  of  L  has  a  Join  and  meet.  A  coamlete 

•  eubset  L  of  a  lattice  M  closed  under  the  Join 
end  meet  operations  defined  on  M  ,  operating  on  subsets  of  L  . 


The  main  result  of  this  section  Is  the  following  theorem. 
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THEOREM  —  The  collection  of  semantic  Interpretations  of  a  signature 
forms  a  complete  lattice,  denoted  L^  . 

PROOF  —  By  definition  the  collection  of  semantic  Interpretations  of 
a  signature  Is  the  collection  of  congruence  relations  on  the  word 
algebra  Wc  •  The  collection  of  congruence  relations  on  an  algebra 
ordered  by  set  containment  Is  known  to  be  a  oomplete  lattloe 
[B lrkhoff  A  Llpson  70],  with  meet  and  join  operations  set 
Intersection  and  congruence  closure  union.  The  top  element  of  this 
lattice  Is  the  trivial  algebra,  containing  one  element  in  each  sort. 

I  "  I 
I  I 


2. 3.  Example 

As  illustration,  a  part  of  the  lattice  of  semantic  Interpretations  of  the 
List  signature  Is  shown  In  Fig.  2.2.  Even  for  such  a  small  example,  , 

like  Wc  ,  Is  infinite  In  size.  Howev«r  ,  the  portion  shown  Is  enough  for  our 
purposes.  Later  examples  will  r.ot  need  any  of  the  missing  pieces.  What  Is 
shown  Is  a  complete  sublattice  of  .  Only  four  constants  from  Wc  and 
their  relationships  are  shown. 
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(A) 

(C) 

(D) 

(A ,  D) 

(B.C) 

A  •  EmptyL 
B  ■  Make! ist (One) 

C  •  Cone (NaKei ist (One) , Make! iat (One) ) 

D  -  Cone (Cone (Make i ist (One) , Make! is t (One) ) , Make  1  is t (One) ) 


Fiqure  2.2  A  portion  of  the  lattice  Lw  for  List 
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Each  box  In  Pig.  2.2  rapraaants  a  ••aantlc  Interpretation.  All  equal 
constants  under  that  Interpretation  are  encloeed  In  parentheeee.  Note  that 
■  Ingle  letters  are  used  ee  abbreviations.  Por  exaaple.  "  (A,  B) "  Man  a  that  the 
conetants  "Empty!"  end  "Ma ke list (One) "  ere  equal.  Each  arc  In  the  lattice  Is 
a  contalnaent  relat lonahlp:  the  eeaantlc  Interpretation  of  the  higher  box 
contains  the  seaantlc  Interpretation  of  the  lower  box.  (Since  there  Is  only 
one  eleaent  In  sort  Elt.  only  the  values  of  type  List  are  shown  In  this  and 
later  lattice  diagrams.) 

To  see  whet  the  coaplete  lattice  ^  looks  like.  Imagine  an  Infinite 
number  of  levels  of  boxes,  esch  level  consisting  of  an  Infinite  number  of 
boxes.  Each  box  on  each  level  (except  st  the  very  top  and  bottom)  Is 
connected  to  some,  but  not  ell,  of  the  boxes  on  the  next  higher  level  and  the 
next  lower  level.  At  the  very  bottom  Is  one  box  connected  to  all  of  the  boxes 
on  the  level  Immediately  above  It,  lust  as  the  top  box  le  connected  to  all 
boxes  on  the  level  Immediately  below  It. 
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3.  Specification 


Tha  formal  theory  described  in  Section  1.2  permits  us  to  write 
collections  of  axioms  using  arbitrary  variable  symbols,  function  symbols,  and 
special  "equality"  function  symbols.  In  defining  the  notion  of  the  "type"  of 
each  term,  a  collection  of  set  names  Is  Involved,  associated  with  each 
collection  of  variables,  and  with  function  domains  and  ranges.  The  syntax  of 
the  wfs  of  this  formal  theory  can  be  made  to  match  the  syntax  of  a  signature, 
setting  the  stage  for  giving  a  signature  the  meaning  of  a  specified 
abstraction. 

DEFINITION  —  A  signature  (S,  F)  Is  specified  by  a  set  of  axioms. 

If  and  only  if  each  type  Involved  In  the  axioms  corresponds  to  a 
member  of  S  In  a  consistent  way  (the  consistency  enters  when 
function  domains  and  ranges  are  considered),  and  each  function 
symbol  In  the  axioms  corrssponds  to  a  member  of  F  . 

A  signature  cannot  be  specified  unless  It  thus  contains  a  sort  name  for  the 
boolean  required  In  the  axiom  formalise,  and  all  the  necessary  equality 
functions  for  Its  sort  names.  (Since  the  types  of  the  equated  terms  make 
clear  which  equality  Is  Involved  In  any  axiom,  we  henceforth  drop  the  type 
subscript,  and  write  simply  Infix  "■").  With  these  minimal  restrictions,  any 
signature  has  many  specifications,  and  each  set  of  axioms  has  a  "natural" 
signature  that  It  specifies.  In  which  the  sort  and  function  names  are  taken 
from  Its  types  and  function  symbols. 

For  example.  Fig.  3.1  contains  a  specification  whose  natural  signature 
has  two  sort  names  and  five  function  names  as  Indicated. 
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SORTS 

List 
Cl  t 


fWCTIONS 


EaptyL: 
Cone : 

Llat  a 

— > 
Llat  — > 

Llat 

Llat 

Head: 

Llat 

— > 

Elt 

Tall: 

Llat 

— > 

Llat 

Makallat: 

El  t 

—  > 

Llat 

One: 

— > 

Elt 

AXIOMS 

H«*d  (EaptyL)  »  On* 

Head  (Makallat  (X))  -  X 

Head  (Cone  (Makallat  (X).  Makallat  (Y)))  -  X 

Tall  (EaptyL)  "  EaptvL 
Tall  (Makallat  (.”))  •  EaptvL 

Tall  (Cone  Otakallat  (X).  Makallat  (Y)))  -  Makcllat  (Y) 
Makallat  (ErrorN)  ■  EaptyL 
Cone  (EaptyL,  L)  ■  L 

Cone  (Makallat  (X),  EaptvL)  -  Makallat  (X) 

Cone  (Makallat  (X).  Cone  (Makallat  (Y),  Makallat  (Z)))  - 

Cone  (Makallat  (X).  Makallat  (Y)) 
Cone  (Cone  (Makallat  (X).  Makallat  (Y)),  L)  • 

Cone  (Makallat  (X),  Makallat  (Y)) 


Figure  3,1  Specification  of  Llat  data  abatractlon 
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3.  1.  Correctness 

As  described  In  Section  1.2,  we  take  the  meaning  of  a  specification  to  be 
any  a ode 1  of  the  axioms,  making  It  possible  to  define  agreement  with 
Intuition: 

DEFINITION  —  Clven  an  Intuitive  data  abstraction  A  and  a  set  of 
axioms  that  specify  the  same  signature,  we  say  that  the  axioms 
correctly  specify  A  If  and  only  If  A  Is  a  model  for  them.  That 
Is,  If  and  only  If  there  exists  an  Interpretation  of  the  axiom 
formalism  Into  A  that  makes  them  all  true. 

Becauae  an  Intuitive  abstraction  and  a  specified  abstraction  are  required  to 
share  a  signature,  the  only  way  that  the  former  can  fall  to  be  a  model  Is  by 
the  assignment  chosen  for  the  function  symbols:  If  the  Intuitive  functions  do 
not  in  fact  satisfy  the  axioms,  the  specification  Is  Incorrect. 

A  specification  contains  semantic  Information  In  the  form  of  axioms.  The 
axioms  may  be  viewed  ae  a  list  of  requirements  that  must  be  satisfied  by  any 
semantic  Interpretation  of  the  signature.  It  Is  our  view  that  these 
requirements  are  minimal,  but  not  maximal  conditions.  A  spec  if lcatlon  does 
not  define  a  unique  semantic  Interpretation,  but  a  collection  of  semantic 
Interpretations. 

3.2.  Semantic  Interpretation 

In  order  to  describe  what  a  specification  means,  we  need  to  characterise 
all  the  semantic  Interpretations  that  agree  with  the  specification.  Some 
Interpretations  must  be  ruled  out,  because  they  do  not  equate  constants  that 
the  specifications  asserts  are  equal.  The  minimal  set  of  equal  constants  that 
must  be  In  a  semantic  Interpretation  that  ageees  with  a  specification  are  In 
the  relation  speceq. 

DEFINITION  —  A  derivation  from  a  specification  S  Isa  finite 
sequence  of  equations  formed  as  follmrs: 

(l)  w  -  w  ,  where  w  is  any  constant  of  Uc  ,  is  an 
equation. 
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(2)  If  wj  •  wi  la  an  aquation  than  •  «[  la  an 
aquation. 

(3)  If  •  wi  and  t#2  ■  Wj  ara  equation*,  than 
•  w -j  la  an  aquation. 

(A)  An  aquation  la  formed  from  an  axiom  of  S  by  an 
aaalgnaiant  of  conatanta  to  varlablea,  where  aach 
occurranca  of  a  variable  x  of  type  S  in  A  la 
conalatently  replaced  by  a  constant  w  of  type  S  . 

(5 )  If  w |  •  V".  and  f(...,c,...)  *  f(...,c,...)  ara 

aquations,  and  c  la  of  t ha  same  type  aa  wj  and  W2  , 
than  f ( . . . ,w j, .. . )  *  f (. . . .wj, •• • )  1*  an  aquation. 

(6)  Nothing  alaa  la  an  aquation. 

The  last  equation  In  a  derivation  la  the  equation  derived.  Two 
elements  w,  and  wi  of  the  constant  word  algebra  Wc  of  a 
specification  S  ara  In  *pacaq  If  and  only  if  the  equation 
wj  ■  wi  can  be  derived  froe  S  .  We  say  that  wj  and  W2 
are  equal  In  apeceq  . 

Our  Intuitive  view  of  *pac If lcatlon  of  a  data  abstraction  la:  two  valuaa 
of  a  sort  ara  equal  because  they  are  Identical,  because  an  axiom  asserts  they 
are  equal,  or  because  they  were  created  by  substitution  of  equal  valuea  for 
the  same  part  of  equal  values.  The  rules  for  forming  equations  In  a 
derivation  capture  Just  those  equalities:  rule  (1)  for  Identical  ues,  rule 

(4)  for  axioms  and  rules  (2),  (3)  and  (3)  for  substitutions. 

LEMW  —  Speceq  la  a  congruence  relation  on  Wc  . 

PROOF  —  Rules  (1),  (2)  and  (3)  for  forming  equations  In  a 
derivation  ara  just  restatements  of  the  reflexive,  symmetric  and 
transitive  properties  of  an  equivalence  relation.  Thus  speceq  Is 
an  equivalence  relation.  To  show  that  it  is  a  congruence  relation 
we  must  demonstrate  that  the  substitution  property  holds.  Suppose 
constants  w(  and  W2  of  type  Sj  are  equal  In  speceq  .  Then 
there  exists  a  derivation  of  wj  •  W2  .  Let 
f:  S |X. . .xS|X. . . Sn_j  - >  Sn  be  a  function.  The  constant  word 
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algebra  Uc  contains  all  values  of  f  ,  and  all  the  elements  of 
Uc  are  constants.  So,  there  exist  constants  °f 

types  Slf,..,Sn.j  and  a  constant 
f (c^, .. . .c^,.. . ,c„_j )  . 

Continuing  from  the  derivation  of  Wj  »  wj  ,  by  rule  (1)  we  derive 
the  equation 

f (cl,...,c1,...,cn_l )  -  f(cl,...,c1,...,cn_1)  . 

Finally,  we  derive 

f  (cp  ,w  j, ...  .Cg.1 )  -  f  (cj , .. .  ,w2, .. .  ,cn-l ) 
by  rule  (5).  l_l 

So,  speceq  Is  a  semantic  Interpretation.  Next,  we  show  that  It  Is  correctly 
spec  If led. 

LEMMA  —  Clven  a  specification  S  ,  Its  semantic  Interpretation 
speceq  Is  a  model  for  S  . 


PROOF  —  This  is  one  place  where  we  cannot  afford  the  confusion  that 
might  arise  from  treating  a  congruence  relation,  speceq  ,  like  an 
algebra.  Let  us  call  the  quotient  algebra  defined  by  speceq 
apecalg  .  The  sets  of  specalg  are  sets  of  equivalence  classes  of 
elements  of  Wc  .  That  Is,  all  elements  of  UQ  that  are  equal  In 
speceq  are  In  one  equivalence  class  In  specalg  .  The  mappings  of 
specalg  are  functions  defined  by  relations  In  speceq  :  Let 

f:  Sjx...xSn_^  - >  Sn  be  a  function  In  the  signature  of  S  .  Let 

"  (w^)  for  1  “  l,...,n  .  The  set  of  all  pairs 

( f  <w  j  ^ . wn-lj*  ln  •P*C*N  defines  a  function  f'  In 

specalg  . 

We  now  show  that  specalg  Is  a  model  of  S  .  Let  wj  ■  wj  be 
any  Instance  of  any  axiom  of  S  formed  by  consistently  replacing 
all  variables  by  constants  of  Vc  .  By  rule  (4)  for  forming 
equations,  wj  -  *2  can  be  derived.  That  means  that  the  functions 
of  specalg  whose  names  appear  ln  v^  and  v^  operate  ln  such  a 
way  that  "vj  »  V2"  has  tha  value  "true"  in  the  Boolean  sort  of 
specalg  .  So,  specalg  Is  a  model  of  S  .  II 


► 
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3.3.  Structure  of  Semantic  Interpretations 

The  congruence  relation  speceq  Is  Just  one  semantic  Interpretation  of  a 
signature.  There  may  be  others  that  agree  with  a  specification. 

DEFINITION  —  A  congruence  relation  Is  said  to  satisfy  a 
specification  If  and  only  if  it  contains  (In  the  set-theoretic 
sense)  the  congruence  relation  speceq  for  that  specification. 

We  can  now  characterize  correct  semantic  Interpretations. 

THEOREM  --  Given  an  intuitive  data  abstraction  A  ,  Its  surrogate 
semantic  Interpretation  A*  and  a  specification  S  with  the  same 
signature.  A  is  correctly  specified  by  S  if  and  only  if  A' 
satisfies  S  . 

PROOF  —  First,  we  show  that  satisfying  S  Implies  correctness. 

Let  v [  -  w-,  be  any  Instance  of  any  axiom  of  S  formed  by 
consistently  replacing  all  variables  by  constants  of  Uc  .  The 
equation  "w,  •  w,"  can  be  derived  by  rule  (*)  of  the  definition  of 
derivations.  So,  wj  and  W2  are  iqual  In  speceq  .  A' 
contains  speceq  ,  so  wj  and  w^  are  equal  In  A*  .  Thus,  every 
axiom  In  S  Is  true  In  the  Interpretation  A*  .  Therefore,  A  Is 
correctly  specified  by  S  . 

Now  we  show  that  correctness  Implies  satisfaction  of  S  . 

Suppose  the  contrary:  A  Is  correct,  but  A'  does  not  contain 
speceq  .  Then,  there  exists  an  equality  wj  •  w;  In  speceq  that 

Is  not  In  the  relation  A'  .  Let  Ej . ET)  be  the  sequence  of 

equations  In  a  derivation  of  vj  •  wj  .  Suppose  an  equation 
Et  :  vj  •  vj  Is  constructed  by  rule  (l>.  Then  the  equality 
”vl  "  vl"  tru*  A*  •  because  A*  Is  a  congruence  relation  and 
admits  all  Identities  of  that  form.  Similarly,  If  Ej  Is 
constructed  by  any  of  the  rules  (2),  (3)  or  (5),  then  It  Is  a 
statement  of  equality  that  must  be  true  In  the  congruence  relation 
A'  .  Suppose  E|  is  constructed  by  rule  (A).  Then,  E|  Is 
formed  Sy  substituting  constants  for  variables  In  an  axiom  of  S  . 

Rut,  every  axiom  Is  true  In  A'  ,  because  A  Is  correctly 
specified.  In  every  case,  Et  Is  e  statement  of  equality  that  must 
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be  true  In  A*  .  Therefore,  Che  last  equation,  "wj  •  wj",  must  be 
true  in  A'  .  •_< 

When  la  an  Intuitive  data  abstraction  correctly  specified?  If  the 
semantic  Interpretation  satisfies  the  specification,  then  all  of  the  values 
that  the  specification  asserts  are  equal  must  be  equal  In  the  Intuitive 
abstraction.  However,  there  may  be  values  that  are  equal  Intuitively,  but  are 
not  necessarily  equal  according  to  the  specification.  Even  though  the 
specification  does  not  completely  describe  the  abstraction,  nothing  In  the 
specification  Is  contradicted.  In  this  caae  we  say  that  the  specification  Is 
still  correct. 

Our  acceptance  of  "incomplete"  specifications  as  correct  Is  motivated  by 
the  use  of  data  abstractions.  In  practice,  the  use  of  an  abstraction  will 
almost  never  require  every  distinct  value  of  each  sort.  Those  values  that  are 
never  used  might  Just  as  well  be  Identified  with  one  value  In  each  sort  that 
Is  used. 

A  particularly  perverse  case  of  correct  Incomplete  specification  Is  the 
vise  of  a  data  abstraction  that  does  not  distinguish  between  any  values  In  any 
sorts.  For  example,  an  abstraction  that  Includes  Input /output  operations  may 
be  used  In  a  program  only  to  read  and  write  values  of  that  abstraction.  Such 
use  Is  characterised  by  the  trivial  Interpretation  that  equates  all  values  of 
each  sort.  Even  the  values  "true"  and  "false"  of  the  sort  Boolean  are  equated 
In  this  Interpretation.  Although  the  dlstlnctlona  that  the  specification 
makes  between  values  of  this  abstraction  are  not  made  by  the  use  of  the 
abstraction.  It  would  not  be  right  to  say  that  the  specification  Is  Incorrect. 

With  the  help  of  the  previous  theorem  we  obtain  a  characterization  of  all 
correctly  specified  data  abstractions  of  a  specification. 

THEOREM  --  The  collection  of  data  abstractions  that  are  correctly 
specified  by  a  specification  form  a  complete  sublattice  of  .  Ue 

denote  the  sublattice  Lg  . 

PROOF  —  By  the  previous  theorem  we  say  argue  about  correctly 
specified  abstractions  In  terms  of  the  surrogate  semantic 
Interpretations  that  satisfy  the  specification.  Each  semantic 
Interpretation  Is  a  congruence  relation  on  Vc  .  The  congruence 
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relations  that  satisfy  the  specification  contain  the  congruence 
relation  speceq  ,  by  definition  of  satisfy  .  The  eleaents  of  L. 
are  contained  in  Lw  ,  because  they  are  all  congruence  relations  on 
«c  .  Therefore,  the  lattice  operations  of  Lw  apply  for  . 

We  need  to  show  that  the  aeet  and  Join  of  every  subset  of  Lg 
Is  contained  In  Lg  .  The  Intersection  of  any  maber  of  sets 
containing  a  cuaaon  subset  contains  that  subset.  So,  the  aeet  of 
any  nuaber  of  congruence  relations  containing  speceq  is  a 
congruence  relation  containing  speceq  .  Slailarly,  the  congruence 
closure  union  of  any  nuaber  of  congruence  relations  containing 
speceq  is  a  congruence  relation  containing  speceq  .  ~ ! 

3.4.  Exaaple 

fig.  3.2  depicts  the  lattice  L3  of  the  List  data  abstraction  specified 
in  Fig.  3.'.  The  seaantlc  lnterpretat ion  speceq  is  represented  by  the  box 
at  the  bottue  of  the  lattice.  Under  this  interpretation  there  are  three 
distinct  values  of  type  List:  "EaptyL  ,•  "Ma»»elist(Onei  ,•  and  the  value 
"Conc(Matcelist(One'  ,Nakellst(One> )  ,•  which  is  equal  to 
■Conc(Conc(Makellst(One'  ,Makeliat(One"  .Makel ist(Onei These  last  two 
values  are  equal  because  of  axloa  111,  (Recall  our  convention  not  to  show  the 
single  value  "One*  of  sort  Elt  in  any  of  the  boxes. ) 


Ardis  4  Hultt 


Structure  of  Specifications  and  Implementations  29 


The  semantic  Interpretation  represented  by  the  box  containing 
"(A),(B,C,D)"  distinguishes  between  the  empty  list  and  all  other  lists,  but 
makes  no  other  distinctions:  all  nonempty  Hats  are  the  saae.  This 
interpretation  satisfies  the  specification,  because  all  of  the  distinctions  It 
aakes  are  aade  by  speceq  .  But,  some  distinctions  aade  by  speceq  are  not 
aade  by  this  Interpretation.  Specifically,  speceq  distinguishes  between 
"Makel 1st (One) "  and  "Cone (Make  1 1st (One) ). " 

Unlike  the  lattice  ^  of  this  signature  (Fig.  2.2)  La  Is  finite.  In 
fact,  there  are  only  flee  semantic  Interpretations  In  L#  .  Note  that  these 
five  Interpretations  appear  In  In  the  saae  relationship  to  one  another  as 

they  do  In  La  .  Why  Is  La  so  much  smaller  than  ?  The  specification  of 
the  List  data  abstraction  defines  a  very  small  speceq  Interpretation.  For 
example,  all  words  of  the  form: 

Cone (Cone ( ...  Cone (Makel 1st (One) .Makel 1st (One) ),xi),X2>...) 
where  the  Xj  are  either  "Makel 1st (One)”  or  "EaptyL",  are  equal  to  the  word: 

Cone (Makel 1st (One) .Makel 1st (One) )  . 

All  words  of  the  form: 

Cone (Cone ( . . . Cone (EmptvL, EaptyL ) , . . . EaptyL ) 
are  equal  to  the  word  "EaptyL".  Because  speceq  collapses  an  Infinite  number 
of  constants  from  Uc  into  four  equivalence  classes,  there  are  only  four 
other  Interpretations  that  can  contain  speceq  . 

All  the  semantic  Interpretations  of  a  data  abstraction  that  satisfy  a 
specification  are  correctly  specified.  However,  all  but  speceq  are 
over-spec  If  ltd.  That  Is,  given  one  of  these  over-specified  Interpretations, 
there  exists  a  specification  S*  with  semantic  Interpretation  speceq*  equal 
to  that  Interpretation.  The  lattice  La*  of  S'  Is  sMller  than  the 
original  lattice  La  .  In  the  example,  the  semantic  Interpretation 
represented  by  the  box  containing  "(A), (B,C,D)"  satisfies  a  specification  S' 
whose  lattice  La'  contains  just  the  two  Interpretations  labelled 
”(A),(B,C,D)"  and  "(A,B,C,D)."  The  seauntlc  Interpretation  represented  by  the 
box  containing  "(A),(B) ,(C,0)"  Is  under-specified  by  S'  ,  because  It  Is  not 
In  the  lattice  La*  .  Under- spec  if led  data  abstractions  are  Incorrectly 
specified.  To  reiterate,  a  data  abstraction  Is  over-specified  by  a 
specification  If  It  Is  in  the  lattice  Lt  of  the  specification  but  Is  not  the 
semantic  Interpretation  speceq  of  that  specification.  A  data  abstraction  Is 


Ardis  &  Haalet  —  Structure  of  Specifications  and  Implementations 

under- spec  if led  if  it  is  not  contained  in  the  lattice  Ls  of  that 
specification. 

3.5.  Relationship  to  Other  Uork 

The  idea  of  using  a  lattice  to  capture  the  structure  of  semantic 
interpretations  of  algebraic  specification  of  data  abstractions  ls  not  new. 
[Clarratana  et  al.  76]  and  [Polajnar  78]  describe  stellar  lattices,  but  with 
auch  aore  attention  to  aatheeatlcal  details.  A  difference  between  L,  and 
their  lattices  ls  the  presence  of  different  interpretations  of  sorts  other 
than  the  sort-of-lnterest  in  L,  .  Consequently,  L,  ls  auch  bigger, 
containing  such  degenerate  Interpretations  as  the  trivial  Interpretation, 
which  equates  all  valuss  to  one  another  in  each  sort. 
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A.  lapleaentatlon 

Tha  Pascal-like  prograaaing  language  Indicated  in  Section  1.1  allows  ua 
to  write  claaa  definitions  containing  certain  typed  objects  (in  the 
progressing- language  sense),  end  with  procedures  using  these  types  ss 
pereaeters  And  results.  The  language  syntax  can  therefore  be  aatched  to  the 
syntax  of  s  signature  in  the  obvious  way. 

DEFINITION  —  A  c lass  definition  involving  s  collection  of  types 
T  ,  and  procedures  P  typed  froa  T  and  using  T  paraaetars,  is 
said  to  l^leasnt  a  signature  (S,  F)  if  and  only  if  a 
correspondence  can  be  established  between  the  naaes  in  S  and  F 
and  the  intuitive  objects  that  are  the  aeanlngs  of  the  types  and 
procedures  in  T  and  P  .  The  correspondence  aust  be  consistent  in 
assigning  procedures  with  typed  paraaeters  to  function  naaes  with 
corresponding  sort  doaalns,  etc.  The  sort-of-lnterest  aust 
correspond  to  the  type  with  the  c lass  naae. 

Aa  defined,  a  given  c lass  lapleaents  s  natural  signature  whose  naaes  are 
taken  froa  the  prog raaalng- language  syntax  Itself.  Any  given  signature  has 
aany  lapleaentatlons,  corresponding  to  the  arbitrary  content  of  the 
prograaalng- language  procedures,  and  to  the  arbitrary  content  of  the  record 
that  represents  the  sort-of-lnterest.  For  exaaple,  the  class  in  Fig.  4.1 
lapleaents  the  saae  signature  specified  by  the  axloas  of  Fig.  3.1. 
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class  List 
record 

values:  array  ( l. . Llstslse]  of  Elt; 

LI atatart:  lnt; 

Llatlength:“Tnt; 
and  record 

f  unc  EeptyL:  List; 

Result:  List; 

* fa suit. LI at  length  :•  1; 

Result. Llststart  :•  0: 

Result. Values  [0]  :»  1; 

EeptyL  : ■  Result; 
end; 

func  Cone  (First,  Second:  List):  List; 
var 

Keault:  List; 

Poe:  lnt; 
begin 

if  List  Equal  (First,  EeptyL) 
then  Cone  :•  Second 
dlid  If  LlstEqual  (Second,  EeptyL) 
thenConc  :-  First; 

Result .List start  :•  0: 

Rasul t. LI  at  length  :•  0; 

Pos  :-  First. Llststart ; 

while  Result. List length  <  First. Llstlength  do 

~^feTult. Values  [Result. Llstlength]  :■  First. Values  (Pos); 
Pos  :■  Next  (Pos) ; 

Result. List  length  : -  Result. Llstlength  ♦  1; 

Pos  T •  Second. Llststart ; 

while  Result. Llstlength  <  (First. Llstlength  ♦ 

Second. Llstlength)  and 
Re suit. List  length  <  3  do 

t. Values  [Result. Llstlength]  :■  Second. Values  [Pos] 
Pos  :•  Next  (Poe) ; 

Re suit. List  length  :■  Result. Llstlength  ♦  1; 
end; 

Cone  :•  Result; 
end; 


f  unc  Hee 


Head  (L:  List):  Elt; 

. Llstlength  “  0 
Head  :•  One 


end; 


then 

Use 


Head  :■  L. Values  [L. Llststart) ; 


mtatlons 


Figure  4.1  lapleaentatlon  of  List  data  abstraction 


Ardis  A  Haalat  —  Structura  of  Spaclf lcatlona  and  Iaplaoantatlons 


func  Tall  (L:  Llat):  Liat; 

~ Raoul t:  Liat; 

Poa:  lot: 

baaln 

Tildl t  :•  EapeyL; 

Poa  Naxt  (L. Llatatart) ; 

whlla  Raaulc. LI  at  length  <  (L. Llatlangth  -  1 )  do 

&a aul c  :•  Cone  (Raaulc, 

Makallat  (L.Valuaa  [Poa])); 
Poa  : ■  Naxt  (Poa); 

Tatf“:»  Raaulc ; 
and; 

func  Makallat  (N:  Ele):  Llac; 

ITaaul c :  Llac; 
baaln 

kaault  !•  EaptyL: 

Makallat  :•  Raaulc; 
and; 

func  Naxt  (Poa:  Inc):  Inc; 
baaln 

if  Koa  «  Llacalza  -  l 
than  Naxe  :■  0 
alia  Naxt  :•  Poa  ♦  1; 


func  LlacEqual  (PI rat.  Sacond:  Llac):  bool; 

if*7lr  at.  Llatlangth  •  l  or 
Sacond. Llatlangth  ■  I 
than  If  Plrat. Llatlangth  • 

Sacond. Llatlangth 
than  LlatEqual  :■  trua 
alaa  Llat  Equal  :•  talaa 
alaa  If  Haad  (Plrat)  ■  Haad  (Sacond)  and 
LlatEqual  (Tall  (Plrat). 

Tall  (Sacond)) 
than  LlatEqual  :•  trua 
alaa  LlatEqual  :•  f alaa: 

and; 

func  Ona:  Elc ; 


f unc  Ona:  tic ; 

i: 


and  claaa 


Plgura  4.1  (cont.)  laplaaantatlon  of  Llat 
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In  cha  syntactic  corraapondanca  between  a  algnatura  and  claaa  coda,  part 
of  cba  Information  of  tha  prograa  goea  unuaad:  tha  dacalia  of  cha  racord  type 
corraspondtng  to  tha  sort-of-lntarast.  Tha  claaa  name  la  aade  to  correspond 
to  thla  diatlnghlahad  sort,  but  tha  racord  components  may  ba  anything.  Thua 
to  aaalgn  a  meaning  arising  from  tha  coda,  tha  corraapondanca  between  tha 
cross-product  languaga-aaanlng  of  this  racord  and  tha  sort-of-lntarast  auat  ba 
glvan.  This  corraapondanca  la  of  coursa  arbitrary,  slnca  only  Its  doaaln  (tha 
cross-product  racord  aat)  appaars  In  tha  prograa.  Thua  although  tha  prograa 
aaanlng  la  unique,  daflnad  by  tha  saaantlcs  of  tha  prograaalng  language  as 
extended  In  Section  1. 1,  tha  abstraction  daflnad  la  not  unique,  slnca  each 
different  raprasantatlon  aapplng  with  tha  proper  doaaln  yields  a  new  aaanlng. 

4.  1.  Corractnaas 

Tha  alapllfled  discussion  in  Section  1. 1  presuaes  that  whan  a  baas  type 
of  tha  programming  language  appaars  In  tha  signature,  tha  Intuitive  aat  of 
this  sort,  and  tha  aaanlng  sat  froa  tha  language,  are  Identical.  In  that  rasa 
nothing  Ilka  a  raprasantatlon  aapplng  (other  than  tha  Identity)  Is  needed  for 
base  types  to  define  Implementation  diagrams  and  correctness.  This  slaple 
view  does  not  correspond  vary  wall  with  reality,  and  does  not  extend  to 
hierarchical  definition  of  abstractions.  Whan  wa  use  (say)  lnt  In 
laplaaentlng  sons  abstraction.  It  Is  seldom  true  that  wa  are  really  using  tha 
full  sat  of  Integers  —  more  likely  sons  special  subset  Is  really  Involved. 
(For  axaapla,  whan  tha  lnt  quantities  are  serving  as  array  subscripts,  the 
actual  aaanlng  sat  Is  probably  Halted  to  tha  legal  bounds.)  And,  whan  one 
previously  daflnad  type  Is  employed  In  tha  definition  of  another,  which  of  tha 
many  possible  representations  of  tha  earlier  type  racord  Is  Intended?  Nothing 
In  tha  syntax  can  say.  For  these  reasons  wa  are  forced  to  define  correctness 
of  an  lap lamentation  In  terms  of  a  collection  of  representation  functions, 
carrying  each  one  of  tha  aaanlng  sets  froa  tha  language  onto  an  Intuitive  sat. 
At  each  level,  only  tha  sort-of-lntarast  appaars  as  an  explicit  tuple  of 
values;  tha  other  sets  have  their  representations,  however. 

DEFINITION  —  Given  a  class  definition  and  an  Intuitive  data 
abstraction  whose  signature  tha  c lass  Implements,  and  raprasantatlon 
functions  aapplng  tha  aaanlngs  of  tha  class  types  to  tha  sorts,  asch 
procedure  of  tha  class  has  sn  lim>  lamentation  diagram,  as  follows: 
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Let  p  be  a  procedure  of  the  lapleaentaclon  corresponding  to 

function  name  f:  Aj  *  ...  x  - >  Aj  of  the  signature,  Aj  the 

sort-of- interest.  (Other  cases  are  slallar,  autatls  mutandis.)  Let 
the  meaning  of  the  class  record  be  the  set  Dj  i  ...  i  Dn  ,  and  let 
Ct  be  the  meaning  set  of  the  Implementation  corresponding  to  A^  , 

for  HI.  Let  R^:  - >  At  ,  except  that 

Rj:  Dj  x  ...  x  DR - >  A |  .  The  Implementation  diagram  for  [> 

la: 

f 

At  X  ...  X  Ay  - - >  Aj 


[p] 

Oj  x  •  •  •  x  Dn  X  ...  x  *  D|  x  ...  x  Dn 


The  upper  part  of  the  diagram  describes  the  Intuitive  abstraction, 
while  the  I owe r  part  describes  the  meaning  of  the  Implementation. 

Ue  say  that  the  Implementation  Is  correct  If  and  only  If  all  of  the 
Implementation  diagrams  commute. 


An  Implementation  abstraction  can  fall  to  be  correct  for  an  Intuitive 
abstraction  only  through  the  semantics  of  functions  and  representations. 
Syntactically  there  can  be  no  failure  to  correspond  because  the  abstractions 
share  the  same  signature.  A  semantic  error  In  a  function  Is  straightforward: 
the  intuitive  function  la  simply  not  (pi  ,  for  the  procedure  p  to  which  It 
corresponds.  However,  It  Is  easy  to  lose  sight  of  the  fact  that  this 
statement  relies  on  a  representation  function  to  bring  the  Intuitive  and 
implemented  domain/range  Into  line.  The  correctness  of  [p]  never  appears  In 
Isolation,  only  In  composition  with  the  necessary  representation  conversions. 
There  Is,  however,  a  case  In  which  (pi  seems  to  stand  on  its  own:  when  the 
representstlon  functions  are  all  Identities.  If  every  Intuitive  and 
Implemented  object  Is  the  same,  then  the  only  errors  can  be  In  the  code 
written  to  manipulate  these  objects.  This  special  case  probably  looms  larger 
In  our  minds  when  we  think  about  Implementations  than  It  ought  to:  one  of  the 
virtues  of  Implementation  Is  that  non-ldentlty  representations  are  convenient, 
and  safely  hidden  in  the  encapsulated  type  definition. 
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4.2.  Semantic  Interpretation 

Just  as  a  specification  defines  a  class  of  semantic  Interpretations  that 
satisfy  the  specification,  an  Implementation  defines  a  class  of  semantic 
Interpretations  that  satisfy  the  Implementation.  In  fact,  most  of  the 
statements  we  made  about  specifications  In  the  previous  section  can  be  made 
about  Implementations.  This  Is  not  hard  to  explain.  Specifications  and 
Implementations  are  both  descriptions  of  the  same  object,  an 
Intuitively-understood  data  abstraction. 

The  first  step  In  describing  semantic  Interpretations  that  satisfy  an 
Implementation  Is  to  define  the  concept  of  a  derivation  for  Implementations. 
Rule  (4)  for  forming  equations  In  a  derivation  (section  3.2)  uses  an  axiom  to 
generate  an  equation.  There  are  no  axioms  In  an  Implementation,  so  this  rule 
can  not  be  used.  However,  the  code  for  functions  that  appear  In  a  constant 
ccn  be  executed,  and  the  result  can  be  checked  to  see  If  It  Is  the  same  as 
other  execution  results. 

DEF INITION  —  The  eval  function  Is  a  mapping  from  Wc  to  the 
lntutltive  programming-language  meaning  sets,  using  the  meaning  of 
the  functions  appearing  In  the  constant: 

eval(f(wj . vn))  -  (f)  ( (W| I . («„]  )  . 

We  can  now  construct  a  new  rule  for  derivations: 

(4')  If  eval(Wj)  ■  «val(vi)  then  wj  •  Wj  Is  an  equation. 

This  gives  us  the  following  definition: 

DEFINITION  —  A  derivation*  Is  a  derivation  (section  3.2)  with  rule 
(4*)  substituted  for  rule  (4).  The  last  equation  Is  said  to  be 
derived*.  Two  constants  wj  and  wj  £  W£  are  equal  In  conceq  if 
and  only  If  the  equation  wj  *  w,  can  be  derived*. 

Conceq  plays  the  role  for  Implementations  that  speceq  plays  for 
specifications.  Any  semantic  Interpretation  that  satisfies  an  Implementation 
must  equate:  Identical  values,  values  that  are  equal  because  the  Implementing 
code  of  both  values  has  the  same  meaning,  and  values  that  are  equal  because  of 
substitution  of  equal  values  for  the  same  part  of  equal  values.  To  be  a  valid 
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semantic  Interpretation  it  must  be  a  congruence  relation  on  Wc  . 

LEMMA  —  Conceq  is  a  congruence  relation  on  Wc  . 

PROOF  —  The  proof  that  speceq  la  a  congruence  relation  (aectlon 
3.2)  doea  not  uae  rule  (4)  of  derivation.  The  other  rulea  for 
forming  equations  In  a  derivation*  are  the  same  aa  for  a  derivation. 
Thus,  the  proof  that  conceq  la  a  congruence  relation  la  Identical 
to  the  proof  that  apeceq  la  a  congruence  relation.  I  ! 

The  aeaantlc  Interpretation  conceq  la  correctly  lapleaented. 

LEMMA  —  Clven  an  lapleaentatlon  I  ,  lta  aeaantlc  Interpretation 
conceq  la  correctly  lapleaented  by  I  . 

PROOF  —  First  ve  show  that  conceq  defines  a  mapping  Rj  that 
serves  as  a  representation  aapplng  of  I  onto  concalg  ,  the 
quotient  algebra  defined  by  conceq  .  Let  (Tj,...,Tn)  be  a  tuple 
of  concrete  types  that  repreaent  the  type  S  .  Define  Rj  on  the 
restricted  set  of  tuples  that  repreaent  constants  In  Wc  by: 

eval(w)  -  (cj,...,cn)  Implies 
RI  !  *cl . cn*  I  >  ^ 

for  soae  constant  w  6  Wc  of  type  S  and  constants 
C|,...,cn  of  the  types  Tj,...,Tn  .  The  notation  "|w|n 
atanda  for  the  equivalence  clasa  of  w  In  concalg  .  We  also 
require: 

Rj(x)  -  Rj(y)  If  and  only  If 
eval(wj)  •  evsKvj) 

for  soae  words  w.  and  w,  .  R ,  la  well-defined,  because 
|wj|  ■  |wj I  In  concalg  whenever  eval(wj)  *  eval(wi)  In 
I  .  For  tuples  (dj,...,dn)  that  do  not  represent  any 
constant  In  Wc  ,  the  value  of  Rj  aay  be  undefined.  These 
tuples  will  never  occur  In  practice,  and  are  not  significant  to 
the  correctness  of  Rf  . 

Next,  we  show  that  I  correctly  lapleaents  concalg 
under  the  aapplng  R^  .  There  exists  an  lapleaentatlon 
diagram: 
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f 

s - >  s 


RI  RI 

tf] 

T |  x  ...  x  Tn— >  Tj  x  ...  x  Tn 

for  each  function  f  in  I  .  Let  w  be  a  constant  of  type 

S  in  Wc  ,  with  representation  (Cf . cQ)  in  I  .  By 

definition  of  Rj  , 

eval(f(w))  -  (cj ',. .. ,cn*  )  Implies 

Rj  :  (cj* . cn')  I - >  I f (w)  i  . 

So,  the  d lag  ram  commutes.  !  I 

4.  }.  Structure  of  Semantic  Interpretations 

Since  the  semantic  interpretation  conceq  was  defined  similarly  to 
speceq  ,  it  is  no  surprise  that  the  relationship  of  an  interpretation 
satisfying  an  implementation  is  the  same  as  the  relationship  of  an 
interpretation  satisfying  a  specification. 

DEFINITION  —  A  semantic  interpretation  is  said  to  satisfy  an 
implementation  if  it  contains  (In  the  set-theoretic  sense)  the 
congruence  relation  conceq  of  that  implementation. 

We  can  now  describe  correctness  in  algebraic  terms. 

THEOREM  —  Given  an  intuitive  data  abstraction  A  ,  its  surrogate 
semantic  interpr  '  >n  A'  and  an  Implementation  I  with  the  same 
signature;  A  is  ^oi.ictly  Implemented  by  I  if  and  only  if  A' 
satisfies  conceq  of  I  . 

PROOF  —  First,  we  show  that  satisfying  conceq  implies 
correctness.  Bv  the  previous  lemma  Rj  is  a  representation  capping 
that  ensures  that  conceq  is  correctly  Implemented  by  I  .  Define 
any  representation  mapping  RA  to  be  the  same  as  Rj  ,  except  that 
it  maps  onto  equivalence  classes  of  A'  Instead  of  conceq  .  Every 
equivalence  class  of  conceq  is  contained  in  an  equivalence  class 
of  A'  .  Sr,  every  diagram  that  commutes  for  Rj  commutes  for 
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»A  • 

Hext,  w«  show  chat  corractnasa  Implies  satisfaction  of  1  . 

Thara  exists  a  rapraaaneatlon  mapping  R'  for  which  every 
lmplaaancaelon  diagram  commute a.  Let  wj  •  wj  ba  an  equality  In 
concaq  .  Lat  (cj,...,cn)  rapraaant  wj  and  (di,...,dn) 
rapraaant  W2  .  Since  concaq  la  correct,  |wj  |  •  |w  2 1  •  Thla 
maana  that  aval(wj)  ■  evaKvj)  •  Correctness  of  A  under  R' 
lapllaa  that 

R'fc! . c„)  «  R  '  (dj . d„)  . 

So,  Wj  »  w-,  In  A'  .  Therefore,  avary  equality  In  concaq  la  In 
a  '  1  “  < 

When  la  an  Intuitive  data  abacractlon  correctly  Implemented’  Juat  aa 
with  specifications,  one  knows  chat  an  Implementation  correctly  lapleaanta  a 
collection  of  data  abacractlona.  If  the  Intuitive  abstraction  has  a 
surrogate  semantic  Interpretation  that  satisfies  the  Implementation,  than  the 
Intuitive  abstraction  la  correctly  Implemented. 

The  user  of  a  data  abstraction  may  not  require  that  the  Implementation 
make  aa  many  distinctions  between  values  as  It  doea.  In  such  caaea  the 
Implementation  la  still  correct  aa  long  aa  the  appropriate  representation 
mapping  la  used.  That  la,  the  results  computed  by  the  Implementation  must  be 
Interpreted  by  a  representation  mapping  that  maps  onto  the  surrogate  semantic 
Interpretation  of  the  Intuitive  data  abatractlon. 

For  example,  a  data  abatractlon  that  requlrea  five  distinct  values  of  a 
sort  might  be  correctly  Implemented  by  an  Implementation  that  can  produce  ten 
distinct  values  of  that  sort.  However,  the  ten  values  must  be  Interpreted  In 
such  a  wav  that  every  operation  on  the  Interpreted  values  behaves  as  the  five 
valuea  would  behave.  The  commutativity  of  the  Implementation  diagram  captures 
this  Idea  precisely.  Mote  that  there  may  not  be  any  Interpretation  of  the  ten 
values  that  behavea  correctly.  The  existence  of  auch  an  Interpretation  la 
only  guaranteed  when  the  Intuitive  abstraction  satisfies  the  semantic 
Interpretation  conceq  of  the  Implementation. 

As  was  the  case  with  specification,  we  obtain  a  characterization  of  all 
correctly  Implemented  data  abstractions. 
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THEOREM  —  The  collection  of  data  abatractlona  that  are  correctly 
lepleaented  by  an  Implementation  fora  a  complete  aublattlce  of  ly  . 

Ue  denote  the  aublattlce  . 

PROOF  —  Thla  proof  la  Identical  to  the  proof  that  Lg  la  a 
complete  aublattlce  of  Ly  (auction  3.3),  except  that  the  congruence 
relatlona  In  all  contain  conceq  lnataad  of  apeceq  . 

4.4.  Example 

Fig.  4.2  deplete  the  lattice  of  the  Llat  data  abatractlon 

Implementation  In  Fig.  4.1.  The  aemantlc  interpretation  conceq  la 
repreaented  by  the  box  at  the  bottom  of  the  lattice.  Under  thla 
Interpretation  there  are  three  dlatlnct  valuea  of  type  Lint: 

"Cone (Make llat (One) .Makellat(One) ) 

MConc(Conc(Makellst(One),Makellet(One)),Makellet(One)),"  and  "EmptvL,"  which 
la  equal  to  "Make llat (One)."  (The  code  for  "EmptyL”  doea  not  create  an  empty 
Hat,  aa  lta  name  lmpllaa,  but  a  Hat  with  one  element  In  It.) 
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The  seaenclc  interpretation  represented  by  the  bos  containing 
"(A,B) ,(C,0)H  only  distinguishes  between  two  values  of  List,  Instead  of  three. 
It  does  not  distinguish  between  "Cone (Make list (One) .Hakellst (One) )M  end 
”Conc(Conc(Nakellst(One) .Hakellst (One) ) .Make list (One) )."  This  Interpretation 
satisfies  conceq  ,  because  all  of  the  distinctions  It  makes  are  made  by 
conceq  . 

Just  as  La  la  small,  containing  five  semantic  Interpretations,  Is 

small,  also  containing  five  Interpretations.  However,  the  Interpretations  In 
L|  are  not  all  the  same  as  those  In  La  .  All  words  of  the  form: 

Cone  ( . . . Cone ( Empty L, EmptyL ) , . . . Empty L ) 
are  equal  to 

Cone (Cone (EmptyL, EmptyL), EmptyL) 

In  conceq  .  Furthermore,  they  are  all  equal  to 

Conc(Conc(Hakellst(One)  .Hakellst (One) ) .Hakellst (One) )  . 

This  Is  certainly  not  the  case  In  speceq  .  Similarly, 

Conc(EmptyL,Hakellst(One) )  and  Hakellst (One)  , 
which  are  equal  In  speceq  are  not  equal  In  conceq  . 

Just  as  a  data  abstraction  can  be  under-specified  or  over-specified.  It 
can  be  under- imp  lamented  or  over- implemented.  Under- implemented  abstractions 
are  not  contained  in  the  lattice  Lj  of  the  lmplcRentatlon.  The 
implementation  Is  Incorrect,  because  It  falls  to  distinguish  between  values 
that  can  be  distinguished  In  the  Intuitive  abstraction.  An  over- Implemented 
data  abstraction  Is  correctly  Implemented,  but  It  Is  not  equal  to  the 
interpretation  conceq  of  that  implementation.  There  exists  an 
implementation  whose  Interpretation  conceq'  is  equal  to  the  over- implemented 
abstraction  and  whose  lattice  L^'  la  smaller  than  the  original  lattice  Lj  . 
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5.  Intersection  of  Iapl Mentation  and  Specification 


Given  a  specification  and  an  intuitive  data  abstraction  one  can  deteralne 
whether  the  intuitive  abstraction  ia  correctly  specified  by  the  specification: 
it  is  if  the  intuitive  abstraction  satisfies  the  specification;  otherwise,  it 
is  not.  In  the  saae  way  one  can  deteralne  whether  an  iapleaentatlon  correctly 
lapleaenta  an  intuitive  data  abstraction.  Both  of  these  determinations  aay  be 
difficult  to  sake,  because  the  intuitive  abstraction  one  has  in  Bind  is  not 
written  down.  Comparing  the  specification  to  the  laplMentatlon  should  be 
easier.  Each  can  be  read  and  analyzed.  In  the  process  of  coaparison  one 
sight  see  if  the  intuitive  abstraction  satisfies  either  or  both. 

Our  view  is  that  specifications  and  iaplMentations  describe  collections 
of  data  abstractions.  These  collections  are  described  by  lattices  ,  Ls  for 
specifications,  L^  for  iapleaentatlons.  We  describe  the  relationship 
between  a  specification  and  an  iapleaentatlon  by  the  overlap  of  their 
lattices. 

Theohem  —  Given  a  specification  S  ,  its  lattice  of  correctly 
specified  data  abstractions  L,  ,  an  iapleaentatlon  I  ,  and  its 
lattice  of  correctly  iapleaented  data  abstractions  Lt  ;  the 
collection  of  data  abstractions  that  are  correctly  specified  by  S 
and  correctly  iapleaented  by  I  fora  a  complete  sublattice  of  Ls 
and  L«  .  We  denote  the  common  sublattice  SL  . 

P3Q0F  —  Viewing  the  lattices  L#  and  as  sets,  the 

intersection  of  L,  and  L^  is  a  set  of  semantic  interpretations 
that  satisfy  both  the  specification  and  the  iapleaentatlon.  Let 
SL  contain  Just  those  interpretations.  SL  ls  not  eapty ,  because 
the  congruence  relation  that  equates  all  eleaents  of  each  sort 
contains  every  congruence  relation.  This  trivial  interpretation 
satisfies  every  specification  and  every  iapleaentatlon  with  the  saae 
signature. 

The  lattice  operations  ,  aeet  and  Join,  are  the  saae  for  L$ 
and  Lt  .  These  operations  apply  to  every  subset  of  SL  .  Every 
congruence  relation  in  SL  contains  the  speceq  and  coneeq 
relations  defined  by  the  specification  and  the  iapleaentatlon.  So, 
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the  aeet  and  Join  of  any  subset  of  SL  are  In  SL  . 

Given  a  specification  and  an  implementation  of  a  data  abstraction,  the 
existence  of  SL  guarantees  that  there  is  at  least  on*  semantic 
interpretation  that  satisfies  both  specification  and  implementation.  If  the 
intuitive  data  abstraction  on*  has  in  mind  is  in  SL  then  the  specification 
and  implementation  are  correct:  they  describe  the  desired  abstraction.  If  the 
intuitive  data  abstraction  on*  has  in  mind  is  not  in  SL  ,  then  either  the 
specification,  the  implementation  or  both  are  incorrect. 

5.1.  Case  Analysis  of  SL 

The  size  of  SL  relative  to  the  sizes  of  Ls  and  Lt  sheds  some  light 
on  the  relationship  between  the  specification  and  the  implementation  of  a  data 
abstraction.  There  are  four  possibilities:  L,  might  be  completely  contained 
in  ,  but  not  equal  to  ;  Lt  might  be  completely  contained  in ,  but  not 

equal  to  L,  ;  L,  and  L^  might  be  equal;  or  L,  and  Lj  might  not  be 
related  by  containment  or  equality. 

When  L9  Is  completely  contained  in,  but  not  equal  to  L<  ,  every 
semantic  interpretation  that  satisfies  the  sped flcatlon  satisfies  the 
implementation.  The  sublattice  SL  is  equal  to  Ls  .  If  the  Intuitive  data 
abstraction  on*  has  in  mind  satisfies  the  specification  it  must  satisfy  the 
implementation.  Every  data  abstraction  that  satisfies  the  specification  ls 
over- implemented  ,  because  there  ls  some  implementation  whose  lattice  L^’  ls 
smaller  than  L^  and  contains  the  desired  abstraction.  There  are  some  data 
abstractions  that  satisfy  the  implementation  (they  are  in  Lj  )  but  do  not 
satisfy  the  specification  (they  are  not  in  L#  >.  These  are  under-specified. 
If  the  intuitive  abstraction  on*  has  in  mind  la  on*  of  these,  the 
specification  must  be  changed.  Too  many  values  are  eqial  in  speceq  .  This 
might  be  corrected  by  removing  or  rewriting  an  axiom.  If  the  intuitive 
abstraction  is  not  in  Lt  then  both  the  specification  and  the  implementation 
eust  be  changed. 
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When  Lt  is  completely  contained  In,  but  not  equal  to  La  ,  every 
semantic  interpretation  that  satisfies  the  implementation  satisfies  the 
specification.  In  this  case  SL  •  Lt  .  Every  data  abstraction  in  SL  is 
over-specified.  If  the  intuitive  abstraction  one  has  in  mind  is  in  SL  ,  both 
specification  and  Implementation  are  correct.  If  the  intuitive  abstraction  is 
In  La  but  not  Lj  ,  then  only  the  implementation  needs  to  be  changed.  Too 
■any  values  are  equal  In  conceq  .  This  might  be  corrected  by  adding  more 
tests  in  the  code  or  by  adding  concrete  variables  to  the  representation  of 
some  type(s).  The  new  variables  would  be  used  to  discriminate  between  values 
of  that  type.  If  the  intuitive  abstraction  is  not  In  L#  then  both 
specification  and  implementation  must  be  changed. 

When  La  and  Lj  are  equal  every  semantic  interpretation  that  satisfies 
the  specification  satisfies  the  implementation,  and  vice  versa: 

SL  ■  L#  •  L^  .  The  semantic  interpretation  speceq  is  also  the  semantic 
interpretation  conceq  ;  lt  is  neither  over-specified  nor  over-implemented. 
Every  other  lnterpretstlon  in  SL  is  both  over-specified  and 
over- implemented.  If  the  intuitive  abstraction  one  has  in  mind  satisfies 
either  the  specification  or  the  implementation  then  lt  satisfies  the  other. 

If  it  does  not  satisfy  one  then  lt  does  not  satisfy  the  other.  This  case  is 
unlikely  to  occur  often  in  practice,  we  feel,  beceuse  the  techniques  of 
specif lcstlon  and  implementation  are  so  different.  Specification  is  more 
algebraic  in  flavor,  and  makes  some  distinctions  easier  (and  some  distinctions 
harder)  to  express  than  in  implementations. 

Finally,  when  La  and  L|  are  not  equal  or  related  by  containment,  some 
semantic  interpretations  satisfy  the  specification  and  not  the  implementation, 
some  interpretations  satisfy  the  implementation  and  not  the  specification. 

Some  interpretations,  all  those  in  SL  ,  satisfy  both,  and  are  both 
over-specified  and  over-implemented.  The  example  in  Fig.  5.1  shows  this  case 
for  the  List  data  abstraction,  whose  specification  and  implementation  uppear 
In  Flg.s  3.1  and  4.1,  respectively.  The  semantic  interpretation  speceq  is 
not  in  Lj  .  If  this  were  one's  Intended  abstraction  the  implementation  would 
need  to  be  changed.  Similarly,  the  specification  would  need  to  be  changed  if 
the  Interpretalon  conceq  were  one’s  Intended  abstraction. 
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Makei ist (One) 

Cone (Makei ist (One) , Make! ist (One) ) 

Cone (Cone (Make  list (One) , Makei ist (One) ) .Makei ist (One) ) 
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5. 2.  Maintenance  Iaauas 

As  we  atated  before,  under-apecif lcation  and  undar-lmplaaentatlon  are 
inatances  of  Incorrect  specification  and  laplaaentatlon,  respectively.  Soae 
values  of  the  data  abatractlon  that  can  be  distinguished  intuitively  are  not 
distinguished  by  the  specification  or  laplaaentatlon.  Over-specification  and 
over-lapleaentatlon  are  not  Incorrect.  The  smaller  the  sublattice  SL  lst 
the  greater  the  probability  Is  that  the  Intuitive  data  abstraction  has  been 
under-specified,  under- Implemented  or  both.  On  the  other  hand,  the  larger  the 
sublattice  SL  Is,  the  greater  the  probability  is  that  the  specification  and 
lapleaentatlon  are  correct. 

In  software  maintenance  one  Is  often  required  to  modify  specifications 
and  Implementations  to  reflect  new  uses  of  the  software.  Robust  software 
survives  many  new  applications  with  little  or  no  required  modification.  For 
data  abstractions  this  quality  of  robustness  Is  reflected  In  the  size  of  the 
sublattice  SL  .  The  larger  the  sublattice  Is,  the  more  Interpretations  are 
allowed.  Since  short  specifications  (l.e.,  few  axioms)  tend  to  have  large 
lattices,  over-specification  is  encouraged  by  robustness  and  clarity.  Saiall 
Implementations  (l.e.,  few  concrete  variables  and  few  lines  of  cods),  on  the 
other  hand,  tend  to  have  small  lattices:  each  distinction  In  values  of  the 
abstraction  "costs"  something,  existence  of  a  new  variable  or  existence  of  a 
new  test.  For  this  reason,  over-implementation  may  be  discouraged. 

It  Is  our  view  that  specifications  and  Implementations  reflect  the  depth 
of  understanding  of  their  author.  Two  different  Interpretations  of  a 
spec  If lcation  or  an  Implementation  may  be  equally  acceptable  if  their 
differences  are  not  Important  to  (that  la,  not  Intended  by)  the  author  or  the 
user.  In  such  cases  the  best  description  of  one's  Intentions  ts  that 
collection  of  Interpretations  that  are  acceptable.  The  lattice  structure 
provides  a  handy  tool  for  describing  ouch  s  collection,  and  for  making  further 
discriminations  when  they  are  needed. 
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A  data  abstraction  is  a  collection  of  sets  together  with  a  collection  of 
functions.  An  intuitive  abstraction  is  unconnected  with  formalism;  the  sets 
and  functions  are  supposed  to  be  known  ab  initio.  Formal  ideas  enter  when  the 
abstraction  is  (i)  implement  ed.  a  conventional  program  written  to  carry  out 
the  operations  on  acutal  data;  and  (ii)  specified,  a  mathematical 
characterization  given  to  precisely  describe  its  sets  and  functions.  The 
intuitive  abstraction,  an  implementation,  and  a  specification  share  a  syntax 
that  names  the  sets  and  functions,  and  gives  the  function  domains  and  ranges 
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20.  Abstract  continued. 


(as  set  names).  The  central  question  for  any  particular  example  of  syntax  is 
whether  the  semantics  of  the  three  ideas  correspons:  does  the  collection  of 
objects  and  operations  a  human  being  was  thinking  of  behave  in  the  way  the 
implementation's  data  and  procedures  behave?  Do  the  mathematical  entities 
behave  as  imagined?  The  questions  can  never  be  answered  precisely,  because 
the  intuitive  abstraction  is  imprecise.  On  the  other  hand,  precise  comparisoi 
of  specification  and  implementation  is  possible. 


This  paper  presents  an  algebraic  comparison  of  specifications  with 
implementations.  It  is  shown  that  these  abstractions  ulways  overlap,  and  havi 
a  common  (lattice)  structure  that  is  valuable  in  understanding  the 
modification  of  code  or  specification.  However,  in  dealing  with  the  precise 
entities  subject  to  formal  analysis,  we  must  not  lose  sight  of  the  intuition 
behind  then.  Therefore,  our  definitions  are  framed  in  terms  of  the  intuitive 
abstraction  a  person  attempted  to  specify  or  implement,  and  we  refer  the 
algebraic  ideas  to  this  standard  whenever  possible. 


Section  1  presents  the  Intuitive  ideas  of  an  abstraction,  its 
implementation,  and  specification.  The  ideas  are  essentially  those  of 
(Hoare  72)  and  (Guttag  77).  Section  2  gives  the  common  formalism  to  be  used 
the  constrant  work  algebra.  In  Sections  3  and  4,  this  is  applied  to 
specification  and  implementation.  Section  5  explores  the  overlap  between  the 
ideas,  and  suggests  that  the  precise  connection  cnn  shed  light  on  the 
imprecise  one  that  is  really  of  interest:  the  intuitive  abstraction  in  a 
person's  mind. 
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